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Abstract: We consider prescriptive type systems for logic programs (as in Godel or Mer- 
cury). In such systems, the typing is static, but it guarantees an operational property: if 
a program is "well-typed", then all derivations starting in a "well-typed" query are again 
"well-typed". This property has been called subject reduction. We show that this property 
can also be phrased as a property of the proof-theoretic semantics of logic programs, thus ab- 
stracting from the usual operational (top-down) semantics. This proof-theoretic view leads 
us to questioning a condition which is usually considered necessary for subject reduction, 
namely the head condition. It states that the head of each clause must have a type which 
is a variant (and not a proper instance) of the declared type. We provide a more general 
condition, thus reestablishing a certain symmetry between heads and body atoms. The con- 
dition ensures that in a derivation, the types of two unified terms are themselves unifiable. 
We discuss possible implications of this result. We also discuss the relationship between the 
head condition and polymorphic recursion, a concept known in functional programming. 

Key-words: Logic programming, (prescriptive) type system, subject reduction, polymor- 
phism, head condition, derivation tree, polymorphic recursion 
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Les programmes logiques bien types ont tout bon 



Resume : On etudie ici les sytemes de typage prescriptif (a la Godel ou Mercury) pour la 
programmation en logique. Dans de tels systemes, le typage est statique, mais il garantit une 
propriete operationnelle: si un programme est "bien type", alors tous les buts obtenus par 
derivation d'un but "bien type" sont eux-meme "bien types". Le systeme est alors dit stable 
par reduction ("subject reduction"). Nous montrons dans ce papier que cette propriete de 
stabilite est en fait aussi declarative. Cette vue declarative nous conduit a reconsiderer une 
condition habituellement admise et necessaire pour la stabilite par reduction, dite condition 
de tete ("head condition"). Cette condition stipule que le type des tetes des clauses d'un 
programme "bien type" doit etre une variante (et non une instance quelconque) du type 
declare de son predicat. II est alors possible de formuler des conditions plus generales qui 
retablissent une certaine symetrie entre les tetes et les atomes du corps, et qui garantissent 
en fait que dans toutes derivations les types des termes unifiables sont eux aussi unifiables. 
On discute enfin les implications possibles d'un tel resultat, en particulier la relation entre 
la condition de tete et la recursion polymorphique, un concept connu dans la programmation 
fonctionnelle. 

Mots-cles : programmation en logique, systeme de type (prescriptif), "subject reduction", 
polymorphisme, condition de tete, arbre de derivation, recursion polymorphique 



Well-Typed Logic Programs Are not Wrong 



3 



1 Introduction 

Prescriptive types are used in logic programming (and other paradigms) to restrict the 
underlying syntax so that only "meaningful" expressions are allowed. This allows for many 
programming errors to be detected by the compiler. Moreover, it ensures that once a program 
has passed the compiler, the types of arguments of predicates can be ignored at runtime, 
since it is guaranteed that they will be of correct type. This has been turned into the famous 
slogan [20, 21] 

Well-typed programs cannot go wrong. 

Adopting the terminology from the theory of the A-calculus [30], this property of a typed 
program is called subject reduction. For the simply typed A-calculus, subject reduction states 
that the type of a A-term is invariant under reduction. Translated to logic programming, 
this means that resolving a "well-typed" query with a "well-typed" clause will always result 
in a "well-typed" query, and so the successive queries obtained during a derivation are all 
"well-typed". 

From this observation, it is clear that subject reduction is a property of the operational 
semantics of a logic program, i.e., SLD resolution [17]. In this paper, we show that it is 
also a property of the proof-theoretic semantics based on derivation trees. This is obtained 
by showing that using "well-typed" clauses, only "well-typed" derivation trees can be con- 
structed, giving rise to the new slogan: 

Well-typed programs are not wrong. 

The head condition, which is a condition on the program (clauses) [13], is usually considered 
to be crucial for subject reduction. The second objective of this paper is to analyse the head 
condition in this new light and open the field for generalisations, of which we introduce one. 

The head condition, also called definitional genericity [16], states that the types of the 
arguments of a clause head must be a variant 1 (and not a proper instance) of the declared 
type of the head predicate. This condition imposes a distinction between "definitional" oc- 
currences (clause heads) and "applied" occurrences (body atoms) of a predicate. In contrast, 
the proof-theoretic view of subject reduction we propose reestablishes a certain symmetry 
between the different occurrences. By this generalisation, the class of programs for which 
subject reduction is guaranteed is enlarged. 

This paper is organised as follows. Section 2 contains some preliminaries. Section 3 
introduces our proof-theoretic notion of subject reduction. Section 4 gives conditions for 
subject reduction, and in particular, a generalisation of the head condition. In Section 5, we 
discuss, in the light of these results, the usefulness of the head condition and its generalisa- 
tion. We also exhibit an interesting relationship between the head condition and polymorphic 
recursion [15]. Section 6 concludes by mentioning possible applications of these results. 

1 A variant is obtained by renaming the type parameters in a type. 
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2 Preliminaries 

We assume familiarity with the standard concepts of logic programming [17]. To simplify 
the notation, a vector such as oi, . . . , o m is often denoted by o. The restriction of a substi- 
tution 9 to the variables in a syntactic object o is denoted as 9\ , and analogously for type 
substitutions (see Subsec. 2.2). The relation symbol of an atom a is denoted by Rel(a). 

When we refer to a clause in a program, we usually mean a copy of this clause whose 
variables are renamed apart from variables occurring in other objects in the context. A 
query is a sequence of atoms. A query Q' is derived from a query Q, denoted Q ~> Q' , if 
Q = ai, . . . , a m , Q' = (ai, . . . , dk-i, B, dk+i, • ■ • , a m )9, and h <— B is a clause (in a program 
usually clear from the context) such that h and are unifiable with MGU 9. A derivation 
Q Q' is defined in the usual way. Given a program P, the immediate consequence 
operator Tp is defined by Tp(M) = {h9 h <— ai, . . . , a m £ P, a\8, . . . , a m 9 6 M}. 

2.1 Derivation Trees 

A key element of this work is the proof-theoretic semantics of logic programs based on 
derivation trees [6]. We recall some important notions and basic results. 

Definition 1 An instance name of a clause C is a pair of the form (C,9), where 9 is a 
substitution. 

Definition 2 Let P be a program. A derivation tree for P is a labelled ordered tree [6] 
such that: 

1. Each leaf node is labelled by _L or an instance name (C, 9) of a clause 2 in P; each 
non-leaf node is labelled by an instance name (C,9) of a clause in P. 

2. If a node is labelled by (h <— ai, . . . , a m , 9), where m > 0, then this node has m 
children, and for i G {1, . . . , m}, the ith child is labelled either _L, or (h' <— B,9') 
where h'Q' — ai9 . 

Nodes labelled _L are incomplete, all other nodes are complete. A derivation tree con- 
taining only complete nodes is a proof tree. 

To define the semantics of logic programs, it is useful to associate an atom with each 
node in a derivation tree in the following way. 

Definition 3 Let T be a derivation tree. For each node n in T, the node atom of n, 
denoted atom(n), is defined as follows: If n is labelled (h <— B,9) , then h9 is the node atom 
°f n > if n is labelled _L ; and n is the ith child of its parent labelled (h <— oi, . . . , a m , 9) , then 
aid is the node atom of n. If n is the root of T then atom(n) is the head of T, denoted 
head(T). 

2 Recall that C is renamed apart from any other clause in the same tree. 



INRIA 



Well-Typed Logic Programs Are not Wrong 



5 



Derivation trees are obtained by grafting instances of clauses of a program. To describe 
this construction in a general way, we define the following concept. 

Definition 4 Let P be a program. A skeleton (tree) for P is a labelled ordered tree such 
that: 

1. Each leaf node is labelled by _L or a clause in P, and each non-leaf node is labelled by 
a clause in P. 

2. If a node is labelled by h <— a±, . . . , a m , where m > 0, then this node has m children, 
and for i S {1, . . . , m}, the ith child is labelled either _L, or h! <— B where Rel(h') = 
Rel(cii). 

The skeleton of a tree T, denoted Sk(T), is the skeleton obtained from T by replacing 
each label (C, 9) with C . Conversely, we say that T is a derivation tree based on Sk(T). 

Definition 5 Let S be a skeleton. We define 

Eq(S) = {ai = hi | there exist complete nodes n, n' in S such that 

• n' is the ith child of n, 

• n is labelled h <— oi, . . . , a m , 

• n' is labelled h! <— B} 

Abusing notation, we frequently identify the set of equations with the conjunction or sequence 
of all equations contained in it. If Eq(S) has a unifier then we call S a proper skeleton. 

Proposition 1 [6, Prop. 2.1] Let S be a skeleton. A derivation tree based on S exists if 
and only if S is proper. 

Theorem 2 [6, Thm. 2.1] Let S be a skeleton and 8 an MGU of Eq(S). Let D(S) be the 
tree obtained from S by replacing each node label C with the pair (C,6\c)- Then D(S) is 
a most general derivation tree based on S (i.e., any other derivation tree based on S is an 
instance of D(S)). 

Example 1 Figure 1 shows a program, one of its derivation trees, and the skeleton of the 
derivation tree. 

To model derivations for a program P and a query Q, we assume that P contains an 
additional clause go <— Q, where go is a new predicate symbol. 

We recall the following straightforward correspondences between derivations, the Tp- 
semantics and derivation trees. 

Proposition 3 Let P be a program. Then 

1. a G lfp(Tp) if and only if a = head(T) for some proof tree T for P, 

2. Q ^* Q' if and only if Q' is the sequence of node atoms of incomplete nodes of a most 
general derivation tree for P U {go <— Q} with head go, visited left to right. 
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h(X)«-q(X),p(X). 

q(D)- 

p(X) <- r(X). 



<h(X)^q(X),p(X), {x/[]}) 



h(X)<-q(X),p(X) 



(q([]),0) (p(X')-r(X'), {x'/Q}) 



q(Q) P (X')<-r(X') 



_L 



Figure 1: A program, a derivation tree and its skeleton 



2.2 Typed Logic Programming 

We assume a type system for logic programs with parametric polymorphism but without 
sub typing, as realised in the languages Godel [12] or Mercury [28]. 

The set of types T is given by the term structure based on a finite set of constructors IC, 
where with each K E IC an arity m > is associated (by writing K/m), and a denumerable 
set U of parameters. A type substitution is an idempotent mapping from parameters to 
types which is the identity almost everywhere. The set of parameters in a syntactic object 
o is denoted by pars(o). 

We assume a denumerable set V of variables. The set of variables in a syntactic object 
o is denoted by vars(o). A variable typing is a mapping from a finite subset of V to T, 
written as {xi : ri, . . . , x m : r m }. 

We assume a finite set T (resp. V) of function (resp. predicate) symbols, each with an 
arity and a declared type associated with it, such that: for each / E T , the declared type 
has the form (ti, . . . , r m , r), where m is the arity of /, (ti, . . . , r m ) E T m , and r satisfies 
the transparency condition [13]: pars(ri, . . . ,r m ) C pars(r); for each p E V , the declared 
type has the form (n, . . . , r m ), where m is the arity of p and (n, . . . ,r m ) E T m . We often 
indicate the declared types by writing /n...r m -»r and j) Tl ... Tm , however we assume that the 
parameters in n, . . . , r m , r are fresh for each occurrence of / or p. We assume that there is 
a special predicate symbol = u , u where u <ElA. 

Throughout this paper, we assume IC, J 7 , and V arbitrary but fixed. The typed lan- 
guage, i.e. a language of terms, atoms etc. based on IC, T , and V , is defined by the rules in 
Table 1. All objects are defined relative to a variable typing U, and _ h . . . stands for "there 
exists U such that U h . . .". The expressions below the line are called type judgements. 

Formally, a proof of a type judgement is a tree where the nodes are labelled with judge- 
ments and the edges are labelled with rules (e.g. see Fig. 2) [30]. From the form of the rules, 
it is clear that in order to prove any type judgement, we must, for each occurrence of a 
term t in the judgement, prove a judgement ...H:t for some r. We now define the most 
general such r. It exists and can be computed by type inferencing algorithms [2]. 

Definition 6 Consider a judgement U h p(t) ^— pi(ii), . . . ,p m (t m ) Clause, and a proof of 
this judgement containing judgements U h i : f, U h i i : f\, . . . , U h i m : f m (see Fig. 2) 
such that (f, fi, . . . ,f m ) is most general (wrt. all such proofs). We call (r,fi, . . . , f TO ) the 
most general type of p(t) <- . . . ,p m {i m ) wrt. U. 
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(Var) 
(Func) 
(Atom) 
( Query) 

( Clause) 

( Program ) 

( Query set) 



Table 1: Rules defining a typed language 
{x : r, . . .} h x : r 



uHj-.ne ■■■ uH m -.T m e 

U\~ fr-^. . .Tm—*T (^1 v •i^ra) «t€) 

£/Hi:ti9 ■■■ UH m :T m e 
U\-p T1 ...T m (ti,—,tm) Atom 
UYAi Atom ■■■ U\~A m Atom 
U\-A 1 ,...,A m Query 

U\-A Atom U\-Q Query 
UhA<—Q Clause 

hCi Clause ■■■ \~C m Clause 
\-{Ci,...,C m } Program 

_\-Qi Query ■■■ _\-Q m Query 
_\-{Qi,...,Qm} Queryset 



is a type substitution 
9 is a type substitution 



U\-t:f 
U F pit) Atom 



U \~ pi(h) Atom 



U \~ Pm(t m ) Atom 



U\-pi(ti),...,p m (t m ) Query 



U\-p(i)<-pi(ti),...,p m (t m ) Clause 



Figure 2: Proving a type judgement 



Moreover, consider the variable typing U' and the proof of the judgement U' h p(t) <— 
pi(t\), . . . ,p m {i m ) Clause containing judgments U' h i : f, U' h i\ : f\, . . . , U 1 h i m : f m 
such that (f, fi, . . . , f m ) is mosi general (wrt. all such proofs and all possible U'). We call 
(f,fi, . . . ,f m ) the most general type of p(t) <-pi(ii), • • • ,p m (t m )- 

The following example explains the difference between the most general type wrt. a fixed 
variable typing, and the most general type as such. 

Example 2 Consider function nil->ii S t(u) an d clause C = p <— X = nil, nil = nil. Fixing 
U = {X : list(int)}, ifte judgement XJ V C Clause can be proven using the judgements 
U h X : list(int) and £/ien {/ h nil : list(int) for each occurrence of nil. 7i can a/so foe 
proven using the judgements U h X : list(int) and i/ien £/ h nil : list(int) f/or i/ie /irsi 
occurrence of nil) and then U h nil : list(V) f/or i/ie oi/ier iwo occurrences of nil). In 
the latter case, we obtain (list(int), list(int), list(V), list(V)), the most general type 
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of C wrt. U. Moreover, (list(V'), list(V'), list(V), list(V)) is the most general type of C 
(choose U' = {X : l±st(V')}). 

Definition 7 If U h x\ = t\, . . . , x rn = t m Query where x\, . . . , x m are distinct variables 
and for each i G {1, . . . , m}, U is a term distinct from Xi, then ({x\/ti, . . . , x m /t m }, U) is 
a typed (term) substitution. 

We shall need three fundamental lemmas introduced in [13]. 3 

Lemma 4 [13, Lemma 1.2.8] Let U be a variable typing and O a type substitution. If 
U h t : o, then UQ h t : aQ. Moreover, if U h A Atom then UQ h A Atom, and likewise 
for queries and clauses. 

Proof: The proof is by structural induction. For the base case, suppose U h x : a where 
x eV. Then x : a e U and hence x : a<d e UQ. Thus U&h x : a<d. 

Now consider U h f Tl ,,, Tm ^ T (ti, . . . ,t m ) : a where the inductive hypothesis holds for 
ti,...,t m . By Rule (Func), there exists a type substitution 8' such that a = tO' and 
U V- U : Ti<3' for each i S {1, . . . , m}. By the inductive hypothesis, UQ h : r^O'O for each 
i G {1, . . . , m}, and hence by Rule (Func), C/9h /n...r m ^r(ii ; • • • , ^m) : t©'0. 

The rest of the proof is now trivial. □ 

Lemma 5 [13, Lemma 1.4-2] Let (9, U) be a typed substitution. IfXJ V t : o then U h tO : a. 
Moreover, if U h A Atom then U h AO Atom, and likewise for queries and clauses. 

Proof: The proof is by structural induction. For the base case, suppose U h x : a where 
x G V. If x9 — x, there is nothing to show. If x/t G 9, then by definition of a typed 
substitution, U h t : a . 

Now consider U h f Tl ...r m ^T{ti, ■ ■ ■ ,t m ) : a where the inductive hypothesis holds for 
ti,...,t m . By Rule (Func), there exists a type substitution 0' such that <r = rO', and 
U \- U : n<d' for each i G {1, . . . , m}. By the inductive hypothesis, U \- UO : nQ' for each 
i G {1, . . . , to}, and hence by Rule (Func), U h f T i...T m ^r{ti, • ■ • , im)# : t0'. 

The rest of the proof is now trivial. □ 

Lemma 6 [13, Thm. 1.4-1] Let E be a set (conjunction) of equations such that for some 
variable typing U, we have U h E Query. Suppose 9 is an MGU of E. Then (9,U) is a 
typed substitution. 

Proof: We show that the result is true when is computed using the well-known Martelli- 
Montanari algorithm [19] which works by transforming a set of equations E — Eq into a 
set of the form required in the definition of a typed substitution. Only the following two 
transformations are considered here. The others are trivial. 

3 Note that some results in [13] have been shown to be faulty (Lemmas 1.1.7, 1.1.10 and 1.2.7), although 
we believe that these mistakes only affect type systems which include subtyping. 
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1. If x = t £ Ek and x does not occur in t, then replace all occurrences of x in all other 
equations in E with t, to obtain Ek+i- 

2. If /(ti, . . . , t m ) = f(s\, . . . , s m ) £ Ek, then replace this equation with t\ = s\, . . . , t m = 
s m , to obtain Ek+i- 

We show that if U h Ek Query and Ek+i is obtained by either of the above transformations, 
then U h Ek+i Query. For (1), this follows from Lemma 5. 

For (2), suppose U h E k Query and f{ti,...,t m ) = f(si, . . . ,s m ) £ E k where / = 
/n...r m ^r- By Rule (Query), we must have U h f(t\, . . . ,t m ) = u , u f( s i, ■ ■ ■ ,s m ) Atom, and 
hence by Rule (Atom), U h f{t\, . . . , i m ) : uQ and [/ h /(si, . . . , s m ) ■ u<d for some type 
substitution 9. On the other hand, by Rule (Func), uQ = r9t and u9 = t9 s for some 
type substitutions 9 S and 9t, and moreover for each i £ {1, . . . , m}, we have U h U : Ti<3 t 
and U \- Si : TiO s . Since parsfa) C pars(r), it follows that Ti9 t = Ti9 s . 4 Therefore 
U \- ti = Si Atom, and so £7 h i?fe+i Query. □ 



3 Subject Reduction for Derivation Trees 

We first define subject reduction as a property of derivation trees and show that it is equiv- 
alent to the usual operational notion. We then show that a sufficient condition for subject 
reduction is that the types of all unified terms are themselves unifiable. 

3.1 Proof-Theoretic and Operational Subject Reduction 

Subject reduction is a well-understood concept, yet it has to be defined formally for each 
system. We now provide two fundamental definitions. 

Definition 8 Let _ h P Program and _ h Q Query set. We say P has (proof-theoretic) 
subject reduction wrt. Q if for every Q £ Q, for every most general derivation tree T 
for P U {go <— Q} with head go, there exists a variable typing U' such that for each node 
atom a of T , U' h a Atom. 

P has operational subject reduction wrt. Q if for every Q £ Q, for every derivation 
Q ^* Q' of P, we have _ h Q' Query. 

The reference to Q is omitted if Q — {Q | _ h Q Query}. The following theorem states 
a certain equivalence between the two notions. 

Theorem 7 Let _ h P Program and _ h Q Queryset. If P has subject reduction wrt. Q, 
then P has operational subject reduction wrt. Q. If P has operational subject reduction, then 
P has subject reduction. 

4 Note how the transparency condition is essential to ensure that subarguments in corresponding positions 
have identical types. This condition was ignored in [21]. 



RR n° 4082 



10 



Deransart & Smaus 



Proof: The first statement is a straightforward consequence of Prop. 3 (2). 

For the second statement, assume U h Q Query, let £ = Q Q' , and T be the 
derivation tree for P U {go <— Q} corresponding to £ (by Prop. 3 (2)). 

By hypothesis, there exists a variable typing U' such that for each incomplete node n 
of T, we have U' h atom(n) Atom. To show that this also holds for complete nodes, we 
transform £ into a derivation which "records the entire tree T". This is done as follows: Let 
P be the program obtained from P by replacing each clause h <— £> with /i <— £>, _B. Let us 
call the atoms in the second occurrence of B unresolvable. Clearly _ h ft. <— B, B Clause 
for each such clause. 

By induction on the length of derivations, one can show that P has operational subject 
reduction. For a single derivation step, this follows from the operational subject reduction 
of P. 

Now let £ = go ~» Q' be the derivation for PU {go <— Q, Q} using in each step the clause 
corresponding to the clause used in £ for that step, and resolving only the resolvable atoms. 
First note that since P has operational subject reduction, there exists a variable typing U' 
such that U' h Q' Query. Moreover, since the unresolvable atoms are not resolved in £, it 
follows that Q' contains exactly the non-root node atoms of T. This however shows that for 
each node atom a of T, we have U' h a Atom. Since the choice of Q was arbitrary, P has 
subject reduction. □ 

The following example shows that in the second statement of the above theorem, it is 
crucial that P has operational subject reduction wrt. all queries. 

Example 3 Let K = {list/1, int/0}, T = {nil^ list(u) , cons UAist(U )^ list(u) , -l^ lnt , 
0-mt, ■ • •}, V = {Piist(int), r llst(U )}, and P be 

p(X) <- r(X). r([X]) <- r(X). 

For each derivation p(X) Q' , we have Q' = p(Y) or Q' Q = r(Y) for some YeV, and so 
{Y : list(int)} h p(Y) Query or {Y : list(U)} h r(Y) Query. Therefore P has operational 
subject reduction wrt. {p(X)|. Yet the derivation trees for P have heads p(Y), p([Y]), p([[Y]]) 
etc., and _ l/p([[Y]]) Query. 

3.2 Unifiability of Types and Subject Reduction 

We now lift the notion of skeleton to the type level. 

Definition 9 Let _ h P Program and S be a skeleton for P. The type skeleton cor- 
responding to S is a tree obtained from S by replacing each node label C n — p(t) <— 
Pi(ii), . . . ,p m {i m ) withp(?) <— pi(fi), . . . ,p m (f m ), where (f,fi, . . . ,f m ) is the most general 
type of C„. 5 For a type skeleton TS , the type equation set Eq(TS) and a proper type 
skeleton are defined as in Def. 5. 

6 Recall that the variables in C n and the parameters in f , fi , . . . , f m are renamed apart from other node 
labels in the same (type) skeleton. 
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go <- p(X) 



go <— p(list(int)) 



p(X')-r(X') 



p(list(int)) <— r(list(int)) 



r([X"])-r(X") 



r(list(U' 



r" 



))-r(U") 



r([X"']) <- r(X"') 



r(list(U' 



))-r(U'") 



Figure 3: A skeleton and the corresponding non-proper type skeleton for Ex. 3 

The following theorem states that subject reduction is ensured if terms are unified only 
if their types are also unifiable. 

Theorem 8 Let _ h P Program and _ h Q Queryset. P has subject reduction wrt. Q if 
for each proper skeleton S of P U {go <— Q} with head go, where Q <E Q, the type skeleton 
corresponding to S is proper. 

Proof: Let S be an arbitrary proper skeleton for P U {go <— Q} with head go, where 
Q £ Q. Let 6 = MGU(Eq(S)) and 6 = MGU{Eq{TS)). For each node n in S, labelled 
p(t) <— pi(fi), . . . ,Pm(*m)_in S and p(f) <— pi(fi), . . . ,p m (f m ) in TS, let C/„ be the variable 
typing such that U n h (i, *i, . . . , t m ) : (f , fi, . . . , f m ). Let 



Consider a pair of nodes n, n' in S such that n' is a child of n, and the equation p(s) — 
p(s') E Eq(S) corresponding to this pair (see Def. 5). Consider also the equation p(a) — 
p(ct') G Eq(TS) corresponding to the pair n, n' in TS. Note that C/„ h s : ct and [/„' h s' : ct'. 
By Lemma 4, f7 h s : ct9 and C/ h s' : ct'6. Moreover, since 6 = MGU(Eq(TS)), we have 
ct9 = (t'6. Therefore U h p(s) = p(s') Atom. Since the same reasoning applies for any 
equation in Eq(S), by Lemma 6, (0, C/) is a typed substitution. 

Consider a node n" in S with node atom a. Since U n » h a Atom, by Lemma 4, {/ h 
a ^4tom. and by Lemma 5, U \- a9 Atom. Therefore P has subject reduction wrt. Q. □ 

Example 4 Figure 3 shows a proper skeleton and the corresponding non-proper type skele- 
ton for the program in Ex. 3. 

In contrast, let JC and T be as in Ex. 3, and V = r llst ( lnt )}. 
Let P be the program shown in Fig. 4- The most general type of each clause is indicated as 
comment. Figure 5 shows a skeleton S and the corresponding type skeleton TS for P. A 
solution of Eq(TS) is obtained by instantiating all parameters with int. 



U = [J U n Q. 



RR n° 4082 



12 



Deransart & Smaus 



app([] ,Ys,Ys) . 
app([X|Xs] ,Ys, [XlZs]) <- 
app(Xs ,Ys ,Zs) . 

r([l]). 

go <- 

app(Xs, [] ,Zs) , 
r(Xs) . 



°/„app (list (U) , list (U) , list (U) ) 
°/.app (list (U) , list (U) , list (U) ) 
°/,app (list (U) , list (U) , list (U) ) 

°/„r(list(int)) 



%app(list (int) ,list(int) ,list(int)) 
°/,r(list(int)) 



Figure 4: A program used to illustrate type skeletons 

go <— app(Xs, [],Zs) , r(Xs) go <— app(list(int) 3 ) , r(list(int)) 

/ \ / \ 

app([X'|Xs'],Ys',[X'|Zs'])^ .... app(list(U') 3 ) 



■([1]) 



r„ni\ r(list(int)) 
app(list(U') 3 ) v v 



app(Xs',Ys',Zs') 
app([],Ys",Ys") app(list(U") 3 ) 

Figure 5: A skeleton and the corresponding type skeleton for Ex. 4 



4 Conditions for Subject Reduction 

By Thm. 8, a program has subject reduction if for each proper skeleton, the corresponding 
type skeleton is also proper. A more general sufficient condition consists in ensuring that any 
type skeleton is proper. We call this property type unifiability. Arguably, type unifiability 
is in the spirit of prescriptive typing, since subject reduction should be independent of the 
unifiability of terms, i.e., success or failure of the computation. However this view has been 
challenged in the context of higher-order logic programming [22] . 

We conjecture that both subject reduction and type unifiability are undecidable. Proving 
this is a topic for future work. 

4.1 The Head Condition 

The head condition is the standard way [13] of ensuring type unifiability. 

Definition 10 A clause C — Pf(t) B fulfills the head condition if its most general 
type has the form (f , . . .). 

Note that by the typing rules in Table 1, clearly the most general type of C must be 
(f, . . .)0 for some type substitution 0. Now the head condition states that the type of the 
head arguments must be the declared type of the predicate, or in other words, 0|>= 0- It has 
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been shown previously that typed programs fulfilling the head condition have operational 
subject reduction [13, Theorem 1.4.7]. By Thm. 7, this means that they have subject 
reduction. 

4.2 Generalising the Head Condition 

To reason about the existence of a solution for the equation set of a type skeleton, we give 
a sufficient condition for unifiability of a finite set of term equations. 

Proposition 9 Let E = {l\ = r±, . . . , l m = r m } be a set of oriented equations, and assume 
an order relation on the equations such that l\ = r\ — * I2 = r<i if r± and I2 share a variable. 
E is unifiable if 

1. for all 1 < i < j < m, ri and rj have no variable in common, and 

2. the graph of — > is a partial order, and 

3. for all i G {1, . . . , m}, k is an instance of rj. 

In fact, the head condition ensures that Eq(TS) meets the above conditions for any type 
skeleton TS. The equations in Eq(TS) have the form p(f a ) = p(fh), where f a is the type of 
an atom and 77, is the type of a head. Taking into account that the "type clauses" used for 
constructing the equations are renamed apart, all the head types (r.h.s.) have no parameter 
in common, the graph of — > is a tree isomorphic to TS, and, by the head condition, f a 
is an instance of fu- In the next subsection, we show that by decomposing each equation 
p(f a ) =p(fh), one can refine this condition. 

4.3 Semi-generic Programs 

In the head condition, all arguments of a predicate in clause head position are "generic" 
(i.e. their type is the declared type). One might say that all arguments are "head-generic". 
It is thus possible to generalise the head condition by partitioning the arguments of each 
predicate into those which stay head-generic and those which one requires to be generic 
for body atoms. The latter ones will be called body-generic. If we place the head-generic 
arguments of a clause head and the body-generic arguments of a clause body on the right 
hand sides of the equations associated with a type skeleton, then Condition 3 in Prop. 9 is 
met. 

The other two conditions can be obtained in various ways, more or less complex to verify 
(an analysis of the analogous problem of not being subject to occur check (NSTO) can be 
found in [6]). Taking into account the renaming of "type clauses", a relation between two 
equations amounts to a shared parameter between a generic argument (r.h.s.) and a non- 
generic argument (l.h.s.) of a clause. We propose here a condition on the clauses which 
implies that the equations of any skeleton can be ordered. 
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In the following, an atom written as p(s, t) means: s and t are the vectors of terms filling 
the head-generic and body-generic positions of p, respectively. The notation p(a, f), where 
a and r are types, is defined analogously. 

Definition 11 Let _ h P Program and _ h C Clause where 

C = Pf o ,<t m+1 (t0,S m +l) <-pi 1)fl (si,ti),...,p^ )fm (s m ,t m ), 

and the type substitution such that (fo, (T m+ i, cti, fi, . . . , <r m , f m )9 is ifte mosi general type 
of C . We call C semi-generic if 

1. for all i,j € {0, . . . , m}, i ^ j, pars(Ti<d) n pars(Tj&) = 0, 

/or a» i e {1,.. .,m}, pars(ai) n Ui<j<mP ors fa') = > 

5. /or aZZ i € {0, . . . , m}, Tj0 = t 4 . 

^4 gMery Q is semi-generic «/ the clause go <— Q is semi-generic. A program is semi- 
generic if each of its clauses is semi-generic. 

Note that semi-genericity has a strong resemblance with nicely-modedness, where head- 
generic corresponds to input, and body-generic corresponds to output. Nicely-modedness 
has been used, among other things, to show that programs are free from unification [1]. 
Semi-genericity serves a very similar purpose here. Note also that a typed program which 
fulfills the head condition is semi-generic, where all argument positions are head-generic. 

The following theorem states subject reduction for semi-generic programs. 

Theorem 10 Every semi-generic program P has subject reduction wrt. the set of semi- 
generic queries. 

Proof: Let Q be a semi-generic query and TS a type skeleton corresponding to a skeleton 
for P U {go <— Q} with head go. Each equation in Eq(TS) originates from a pair of nodes 
(n,rii) where n is labelled C = p(ro,<x TO +i) <— pi(<7i,fi), . . . ,p m (o'm,f m ) and rn is labelled 
Ci = Pi(fl,a' i ) <—..., and the equation is p^f^tr-) = Pi((Ti,fi). Let Eq' be obtained from 
Eq(TS) by replacing each such equation with the two equations Oi = f[, a[ = fi. Clearly 
Eq 1 and Eq(TS) are equivalent. Because of the renaming of parameters for each node and 
since TS is a tree, it is possible to define an order — > on the equations in Eq' such that for 
each label C defined as above, o\ — f[ —■* E\ — - > a[ — f\ — » . . . — - > a m = f' m — - > E m --■ » 
o' m = f m , where for each i £ {1, . . . , m}, Ei denotes a sequence containing all equations e 
with pars(e) n pars{Ci) ^ 0. 

We show that Eq' fulfills the conditions of Prop. 9. By Def. 11 (1), Eq' fulfills condition 1. 
By Def. 11 (2), it follows that — > is a subrelation of --■», and hence Eq' fulfills condition 2. 
By Def. 11 (3), Eq' fulfills condition 3. 

Thus Eq(TS) has a solution, so TS is proper, and so by Thm. 8, P has subject reduction 
wrt. the set of semi-generic queries. □ 

The following example shows that our condition extends the class of programs that have 
subject reduction. 
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p(U,list(V)) <- q(list(U),W),q(list(W),V) 



q(U',list(U')) q(U",list(U")) 



Figure 6: A type skeleton for a semi-generic program 



Example 5 Suppose K. and T define lists as usual (see Ex. 3). Let V = {pu.v, qu.v} and 
assume that for p, q, the first argument is head-generic and the second argument is body- 
generic. Consider the following program. 



This program is semi-generic. E.g. in the first type clause the terms in generic positions 
are U, W, V; all generic arguments have the declared type (condition 3); they do not share a 
parameter (condition 1); no generic argument in the body shares a parameter with a non- 
generic position to the left of it (condition 2). A type skeleton is shown in Fig. 6. 

As another example, suppose now that K. and T define list and integers, and consider 
the predicate r/2 specified as r(l, []),r(2, [[]]), r(3, [[[]]]) . . .. Its obvious definition would be 



One can see that this program must violate the head condition no matter what the declared 
type ofr is. However, assuming declared type (int, list(U)) and letting the second argument 
be body-generic, the program is semi-generic. 

One can argue that in the second example, there is an intermingling of the typing and 
the computation, which contradicts the spirit of prescriptive typing. However, as we discuss 
in the next section, the situation is not always so clearcut. 

5 What is the Use of the Head Condition? 

The above results shed new light on the head condition. They allow us to view it as just 
one particularly simple condition guaranteeing type unifiability and consequently subject 
reduction and "well-typing" of the result, and hence a certain correctness of the program. 
This raises the question whether by generalising the condition, we have significantly enlarged 
the class of "well- typed" programs. 

However, the head condition is also sometimes viewed as a condition inherent in the type 
system, or more specifically, an essential characteristic of generic polymorphism, as opposed 



p(X,[Y]) <- 

q([X],Z), q([Z],Y). 
q(X, [X]) . 



'/.p(U,list(V)) <- 

'/. q(list(U) ,W) , q(list(W) ,V) . 

'/.q(U,list(U)) . 



r(l,G). 

r(J,[X]) <- r(J-l,X). 
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to ad-hoc polymorphism. Generic polymorphism means that predicates are defined on an 
infinite number of types and that the definition is independent of a particular instance of 
the parameters. Ad-hoc polymorphism, often called overloading [20], means, e.g., to use 
the same symbol + for integer addition, matrix addition and list concatenation. Ad-hoc 
polymorphism is in fact forbidden by the head condition. 

One way of reconciling ad-hoc polymorphism with the head condition is to enrich the 
type system so that types can be passed as parameters, and the definition of a predicate 
depends on these parameters [18]. Under such conditions, the head condition is regarded as 
natural. 

So as a second, more general question, we discuss the legitimacy of the head condition 
briefly, since the answer justifies the interest in our first question. 

In favour of the head condition, one could argue (1) that a program typed in this way does 
not compute types, but only propagates them; (2) that it allows for separate compilation 
since an imported predicate can be compiled without consulting its definition; and (3) that 
it disallows certain "unclean" programs [23]. 

In reality, these points are not, strictly speaking, fundamental arguments in favour of the 
head condition. Our generalisation does not necessarily imply a confusion between compu- 
tation and typing (even if the result type does not depend on the result of a computation, 
it may be an instance of the declared type). Moreover, if the type declarations of the pred- 
icates are accompanied by declarations of the head- and body-generic arguments, separate 
compilation remains possible. Finally, Hanus [11] does not consider the head condition to 
be particularly natural, arguing that it is an important feature of logic programming that 
it allows for lemma generation. 

We thus believe that the first question is, after all, relevant. So far, we have not been 
able to identify a "useful", non-contrived, example which clearly shows the interest in the 
class of semi-generically typed programs. The following example demonstrates the need for 
a generalisation, but also the insufficiency of the class defined in Def. 11. 

Example 6 Let /C = {t/l,int/0} and 

F = {-l^int, O^int, . . . , C^ t (u), gu->t(U), f t(t(U))->t(U) }■ 

For all i > 0, we have _ h g*(c) : t m (U) and _ h f^g^c)) : t(U). This means that the 
set {a | 3s, t. s is subterm oft, _ h s : a, _ h t : t(U)} is infinite, or in words, there are 
infinitely many types that a subterm of a term of type t (U) can have. This property of the 
type t(U) is very unusual. In [27], a condition is considered (the Reflexive Condition,) which 
rules out this situation. 

Now consider the predicate f gs/2 specified as f gs(i, f l (g l (c))) fieNj. Figure 7 presents 
three potential definitions of this predicate. The declared types of the predicates are given by 
V = {fgsl int:t(U ), gsl lnt:t(U ), fgs2 lnt)t („), fgs3 lntrt(u) , f sl lntrt(u) int , f s2 intit ( U ) jint , 
g s 2int,t(u),t(v)i f g s 3_ aux int.t(u),t(u)}- The first solution is the most straightforward one, 
but its last clause does not fulfill the head condition. For the second solution, the fact clause 
gs2(0,x,x) . does not fulfill the head condition. The third program fulfills the head condition 
but is the least obvious solution. 
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fgsl(I,Y) <- 
fsl(I,Y,I) . 



fgs2(I,Y) <- 
fs2(I,Y,I) . 



fgs3(I,X) <- 

fgs3_aux(I,c,X) . 



fsl(I,f (X),J) <- 
fsl(I-l,X,J) . 



f s2 (I ,f (X) , J) <- 



fs2(I-l,X,J) . 



f gs3_aux(I ,X,f (Y) ) <- 

fgs3_aux(I-l,g(X) ,Y) . 
fgs3_aux(0,X,X) . 



fsl(0,X,J) <- 

gsl(J,x) . 



fs2(0,X,J) <- 
gs2(J,X,c) . 



gsl(J,g(X)) < 
gsl(J-l,X) . 
gsl(O.c) . 



gs2(J,X,Y) <- 

gs2(J-l,X,g(Y)) . 
gs2(0,X,X) . 



Figure 7: Three potential solutions for Ex. 6 



For the above example, the head condition is a real restriction. It prevents a solution 
using the most obvious algorithm, which is certainly a drawback of any type system. We 
suspected initially that it would be impossible to write a program fulfilling the specification 
of f gs without violating the head condition. 

Now it would of course be interesting to see if the first two programs, which violate the 
head condition, are semi-generic. Unfortunately, they are not. We explain this for the first 
program. The second position of gsl must be body-generic because of the second clause 
for gsl. This implies that the second position of f si must also be body-generic because of 
the second clause for f si (otherwise there would be two generic positions with a common 
parameter). That however is unacceptable for the first clause of f si (X has type t(t(U)), 
instance of t(U)). 

It can however be observed that both programs have subject reduction wrt. the queries 
f gsj(i, Y) for i S IN and j = 1,2. In fact for these queries all type skeletons are proper, but 
it can be seen that the equations associated with the type skeletons cannot be ordered. This 
shows that the condition of semi-genericity is still too restrictive. 

There is a perfect analogy between gsl and r in Ex. 5. 

To conclude this section, note that our solution to the problem in Ex. 6 uses polymorphic 
recursion, a concept previously discussed for functional programming [15]: In the recursive 
clause for fgs3_aux, the arguments of the recursive call have type (int, t(t(U)), t(t(U))), 
while the arguments of the clause head have type (int, t(U), t(U)). If we wrote a function 
corresponding to f gs3_aux in Miranda [31] or ML, the type checker could not infer its type, 
since it assumes that recursion is monomorphic, i.e., the type of a recursive call is identical 
to the type of the "head". In Miranda, this problem can be overcome by providing a type 
declaration, while in ML, the function will definitely be rejected. This limitation of the ML 
type system, or alternatively, the ML type checker, has been studied by Kahrs [14]. 

There is a certain duality between the head condition and monomorphic recursion. When 
trying to find a solution to our problem, we found that we either had to violate the head 
condition or use polymorphic recursion. For example, in the recursive clause for gsl, the 
arguments of the recursive call have type (int, t(U)), while the arguments of the clause head 
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have type (int, t(t(U))), which is in a way the reverse of the situation for fgs3_aux. Note 
that this implies a violation of the head condition for any declared type of gsl. It would be 
interesting to investigate this duality further. 

6 Conclusion 

In this paper we redefined the notion of subject reduction by using derivation trees, leading 
to a proof-theoretic view of typing in logic programming. We showed that this new notion 
is equivalent to the operational one (Thm. 7). 

We introduced type skeletons, obtained from skeletons by replacing terms with their 
types. We showed that a program has subject reduction if for each proper skeleton, the type 
skeleton is also proper. Apart from clarifying the motivations of the head condition, it has 
several potential applications: 

• It facilitates studying the semantics of typed programs by simplifying its formulation in 
comparison to other works (e.g. [16]). Lifting the notions of derivation tree and skeleton 
on the level of types can help formulate proof-theoretic and operational semantics, just 
as this has been done for untyped logic programming with the classical trees [3, 6, 9]. 

• The approach may enhance program analysis based on abstract interpretation. Proper 
type skeletons could also be modelled by fixpoint operators [4, 5, 10]. Abstract inter- 
pretation for prescriptively typed programs has been studied by [25, 27], and it has 
been pointed out that the head condition is essential for ensuring that the abstract 
semantics of a program is finite, which is crucial for the termination of an analysis. It 
would be interesting to investigate the impact of more general conditions. 

• This "proof-theoretic" approach to typing could also be applied for synthesis of typed 
programs. In [29], the authors propose the automatic generation of lemmas, using 
synthesis techniques based on resolution. It is interesting to observe that the generated 
lemmas meet the head condition, which our approach seems to be able to justify and 
even generalise. 

• The approach may help in combining prescriptive and descriptive approaches to typ- 
ing. The latter are usually based on partial correctness properties. Descriptive type 
systems satisfy certain criteria of type-correctness [7], but subject reduction is difficult 
to consider in such systems. Our approach is a step towards potential combinations 
of different approaches. 

We have presented a condition for type unifiability which is a refinement of the head 
condition (Thm. 10). Several observations arise from this: 

• Definition 11 is decidable. If the partitioning of the arguments is given, it can be 
verified in polynomial time. Otherwise, finding a partitioning is exponential in the 
number of argument positions. 
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• The refinement has a cost: subject reduction does not hold for arbitrary (typed) 
queries. The head condition, by its name, only restricts the clause heads, whereas our 
generalisation also restricts the queries, and hence the ways in which a program can 
be used. 

• As we have seen, the proposed refinement may not be sufficient. Several approaches 
can be used to introduce further refinements based on abstract interpretation or on 
properties of sets of equations. Since any sufficient condition for type unifiability 
contains at least an NSTO condition, one could also benefit from the refinements 
proposed for the NSTO check [6]. Such further refined conditions should, in particular, 
be fulfilled by all solutions of Ex. 6. 

We have also studied operational subject reduction for type systems with subtyping [26]. 
As future work, we want to integrate that work with the proof-theoretic view of subject 
reduction of this paper. Also, we want to prove the undecidability of subject reduction and 
type unifiability, and design more refined tests for type unifiability. 
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